In the area of conventional business service development, there are, in general, three major roles, each role having specific tools to address its needs.
Application architects are primarily concerned with defining the contracts of the business services to meet the business requirements. An application contract consists of one or more interface definitions, reflecting the right level of interface granularity and service behavior such as operations exposed and their inputs and outputs.
An important aspect of the architect's task here is to ensure that existing interface types are reused so that multiple interface types and messages are not reinvented to fulfill similar requirements.
Once the correct interfaces have been defined, the application developers are ready to implement those interfaces. This often involves writing code that implements business logic. The developers also have to be able to unit test the code that they have just written.
Finally, once the code has been developed, it can be given to the system administrators for configuration, deployment and management. They can then configure the runtime execution environment for the newly developed service and deploy the application. Once deployed, the application can then be managed through the means available in the environment.
In the conventional development model, the applications are developed from scratch. This allows the users to perform top-down design and leverage the full capabilities of the available technologies since no baggage needs to be carried from the past.
Currently, there are 5 major phases of the lifecycle of the business services. In the model phase, the application architects design the interfaces for the business services to be developed. Once the interfaces have been designed, the business logic is developed by the developers of the system. The system architects then configure the runtime for the business service and the administrators then deploy and manage the business services.
In many cases, the business services already exist but are not manageable. These services may be either 3rd party off-the-shelf (COTS) applications or custom applications developed in-house or by system integrators.
This style of development is bottom-up development where the interfaces are actually constructed based on existing applications. The architects first use introspection to reverse engineer metadata from the existing applications. These applications may exist in one of many supported technologies such as Java classes, CORBA, EJB's, existing web services or COTS packages such as SAP or Siebel. Introspection would result in one-to-one interface generation. However, in real world, these interfaces may need to be refactored. Refactoring involves either suppressing some of the operation in an interface, creating brand new ones, combining two or more interfaces (contract aggregation) or splitting a contract into two or more contracts (contract dissemination).
It should be noted that the existing applications could also be web services. The process should however be no different than that for 3rd party COTS or custom applications supporting a particular technology.
Business logic generally does not change in nature. However, the underlying technologies are changing very rapidly. For example, there are a number of new standards that are being developed to address various aspects of distributed business services. Many standards do not have any sort of industry consensus and many areas have competing standards. However, the applications have to be developed today. Typically, the business services are written to provide all the other necessary functionality, such as security and others (application infrastructure services) that do not actually contribute to the business behavior itself. As the standards and technologies for these other services (application infrastructure services) evolve, the business services have to be modified and enhanced in order to take advantage of them. Furthermore, in the current state of the art, the configuration and deployment of these services is specific to a particular underlying environment and the underlying products.
In particular, it is often difficult and time-consuming for a system administrator to properly configure business and infrastructure services when they are being integrated, deployed, and managed. Commonly, this sort of configuration must be performed manually before any code is generated, and often must be performed for each service without any property integration between services.
There is, therefore, a need in the art for an improved system, method, and computer program product for configuring services in a distributed network.